-
Notifications
You must be signed in to change notification settings - Fork 23
Allow nogil for most types of methods #181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This requires a change in conversion providers. +Some other cleanups.
|
I will fix tests because of newer typing syntax |
poshul
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Any idea what sort of performance improvements we are likely to see?
|
Probably none out of the box. This brings some responsibilities for the user with it but you can decide which functions are safe to use. |
timosachsenberg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not super confident that I understand all parts. Would be great if in general methods would contain a brief comment e.g.the new _split one etc.
|
This is a breaking change. Be prepared to fix OpenMS if you merge this. |
|
Given that we already need to do some fixes for OpenMS to get it to work with the current develop version of autowrap, I'm good merging this in and planning to have the core group sit down and fix at some point in the future. |
|
what needs to be done to work with the current develop version of autowrap otherwise? |
|
and what would need to be fixed? |
|
|
@timosachsenberg @claude This might be something for you guys. Maybe we should even default to wrapping without GIL. I am only wondering what happens if you start a threadpool in python and then each thread calls a function parallelized with OpenMP. |
|
ok I can take a look. can you review the other PRs? especially the memory view one could require some input what you had in mind |
Additional commit availableA new commit has been pushed to Commit: This fixes the C++17 STL containers (StdOptionalConverter, StdStringViewConverter) and other converters that were missing the 4th Changes in this commit:
All now return the proper 4-tuple and have Tests: 165 passed, 1 skipped (environment issue unrelated to changes) To merge this, either:
|
|
based and finished (kind of) in other pr |
Summary
This PR enables
nogilsupport for most types of methods in autowrap-generated code. When a method is marked withnogilin the PXD file (e.g.,void process() nogil), the generated wrapper will release Python's Global Interpreter Lock (GIL) before calling into C++, allowing true parallelism.Key Changes
input_conversion()now returns a 4-tuple(code, call_as, cleanup, decl)wheredeclis a tuple(declaration, call_expression)for split declaration in nogil contextscall_method()signature: Addedwith_cdefparameter to control whether to includecdef(not allowed insidenogil:blocks)>=3.1for improved nogil supportUpdated Converters
All TypeConverter classes now support nogil:
nogil + OpenMP Thread Interaction Analysis
When a
nogil-marked method (e.g., in pyOpenMS) internally uses OpenMP for parallelism:How It Works
with nogil:blockSafety Considerations
with gil:to reacquire GIL firstExample Flow
Bottom Line
This is safe and beneficial for libraries like OpenMS that use OpenMP internally:
Test Plan
gil_testing.hppverifies GIL is properly releasedReferences